-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mem-ruby, configs: Add a generic CHI controller as a stepping stone for ruby+classic topology #1084
base: develop
Are you sure you want to change the base?
Conversation
Would you be willing to talk about this in the next gem5-dev meeting? This is super cool! |
Will it be on the 9th of May? If that's the case I won't be able to attend it, though @tiagormk (who's the author of these changes/feature) might be |
Yes, it will be on May 9th at 4pm UTC. @tiagormk, would you be available to attend and discuss this improvement? |
Unfortunately I have a conflict that time. But I could join the June meeting probably. |
Cool! I notice that you have many empty implementations like
We are facing similar things. I think there should be something defining a cleaner interface of |
Yes I saw the issue few days ago and I also noticed the similarity
Yes, that is mainly because this controller constitutes a pure virtual interface. We have a subclass we will upstream which overrides most of these methods to be able to transform a gem5 classic packet into a ruby packet. The reason why we don't commit to a sequencer in the CHIGenericController is because we want to be able to support the case of a sequencer-less configuration. If I understood correctly this might be a useful scenario for you as well.
Thanks I will look at your draft if I find some time. I will also keep you in the loop if there is an update. Most likely we will discuss this feature at the next gem5 developer meeting. |
Allow the number of controllers of an specific type to incremented externally. This enables a custom implementation of AbstractController to pose as an specific SLICC-generated machine. See subsequent patches for examples. Change-Id: I0b9a3fc82439c18156e377363cebc0385b47f1cd
Change-Id: I9cd780597c4680513d9cbeb8dda2e13f2a1faf56
This snoop reponse is not generated internally by the SLICC implementation, but is required for compatibility with classic caches which may remain in SD state while returning SC data upon receiving a converted SnpShared. Change-Id: I5270b29c8863c7afd8abc39b3c7978b95330c183
Change-Id: I49c24e8b99932f8ae88511bb7a08a94f59ce7d29
Component implementing a generic controller that allow classic caches interaction with Ruby/CHI. The CHIGenericController provides an interface to send/receive CHI messages to/from the interconnect. This is implement in C++ rather then SLICC. This controller is seen as a MachineType:Cache by the CHI implementation in SLICC. Change-Id: I3afc4363f4290095c2f7428c8487bccd932e0300
This commit allows top level configs making use of the Ruby module to define node generation callbacks. The config_ruby function will check the system object for two factory methods 1) _rnf_gen, if defined, will be called to generate RNFs 2) _mn_gen, if defined, will be called to generate MNs Change-Id: I9daeece646e7cdb2d3bfefa761a9650562f8eb4b Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This PR is mainly adding a CHIGenericController class to model a coherence controller entirely
in C++ to work with ruby. This is a stepping stone towards supporting a hybrid setup with
classic caches + ruby.